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Raptor Forward Error Correction (FEC) Schemes for FECFRAME 
Abstract 


This document describes Fully-Specified Forward Error Correction 
(FEC) Schemes for the Raptor and RaptorQ codes and their application 
to reliable delivery of media streams in the context of the FEC 
Framework. The Raptor and RaptorQ codes are systematic codes, where 
a number of repair symbols are generated from a set of source symbols 
and sent in one or more repair flows in addition to the source 
symbols that are sent to the receiver (s) within a source flow. The 
Raptor and RaptorQ codes offer close to optimal protection against 
arbitrary packet losses at a low computational complexity. Six FEC 
Schemes are defined: two for the protection of arbitrary packet 
flows, two that are optimized for small source blocks, and two for 
the protection of a single flow that already contains a sequence 
number. Repair data may be sent over arbitrary datagram transport 
(e.g., UDP) or using RTP. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by 

the Internet Engineering Steering Group (IESG). Further 
information on Internet Standards is available in Section 2 of 

RFC 5741. 


Information about the current status of this document, any 
errata, and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6681. 
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1. Introduction 


The "Forward Error Correction (FEC) Framework" [RFC6363] describes a 
general framework for the use of Forward Error Correction in 
association with arbitrary packet flows. Modeled after the FEC 
Building Block developed by the IETF Reliable Multicast Transport 
working group [RFC5052], the FEC Framework defines the concept of FEC 
Schemes that provide specific Forward Error Correction Schemes. This 
document describes six FEC Schemes that make use of the Raptor and 
RaptorQ FEC codes as defined in [RFC5053] and [RFC6330]. 


The FEC protection mechanism is independent of the type of source 
data that can be an arbitrary sequence of packets, for example audio 
or video data. In general, the operation of the protection mechanism 
is as follows: 


o The sender determines a set of source packets (a source block) to 
be protected together based on the FEC Framework Configuration 
Information. 


o The sender arranges the source packets into a set of source 
symbols, each of which is the same size. 


o The sender applies the Raptor/RaptorQ protection operation on the 
source symbols to generate the required number of repair symbols. 


o The sender packetizes the repair symbols and sends the repair 
packet(s) and the source packets to the receiver(s). Per the FEC 
Framework requirements, the sender MUST transmit the source and 
repair packets in different source and repair flows, or in the 
case Real-time Transport Protocol (RTP) transport is used for 
repair packets, in different RTP streams. 


o At the receiver side, if all of the source packets are 
successfully received, there is no need for FEC recovery and the 
repair packets are discarded. However, if there are missing 
source packets, the repair packets can be used to recover the 
missing information. 


The operation of the FEC mechanism requires that the receiver is able 
to identify the relationships between received source packets and 
repair packets, in particular, which source packets are missing. In 
many cases, data already exists in the source packets that can be 
used to refer to source packets and to identify which packets are 


missing. In this case, we assume it is possible to derive a 
"sequence number" directly or indirectly from the source packets, and 
this sequence number can be used within the FEC Scheme. This case is 
referred to as a "Single sequenced flow". In this case, the FEC 
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Source Payload ID defined in [RFC6363] is empty and the source 
packets are not modified by the application of FEC, with obvious 
backwards compatibility advantages. 


Otherwise, it is necessary to add data to the source packets for FEC 
purposes in the form of a non-empty FEC Source Payload ID. This is 
referred to as the "arbitrary packet flow" case. This document 
defines six FEC Schemes, two for the case of a single sequenced flow 
and four for the case of arbitrary packet flows. 


2. Document Outline 
This document is organized as follows: 


o Section 5 defines general procedures applicable to the use of the 
Raptor and RaptorQ codes in the context of the FEC Framework. 


o Section 6 defines a FEC Scheme for the case of arbitrary source 
flows and follows the format defined for FEC Schemes in [RFC6363]. 
When used with Raptor codes, this scheme is equivalent to that 
defined in 3GPP TS 26.346, "Multimedia Broadcast/Multicast Service 
(MBMS); Protocols and codecs" [MBMSTS]. 


o Section 7 defines a FEC Scheme similar to that defined in Section 
6 but with optimizations for the case where only limited source 
block sizes are required. When used with Raptor codes, this 
scheme is equivalent to that defined in ETSI TS 102.034, "Digital 
Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services 
over IP Based Networks" [DVBTS] for arbitrary packet flows. 


o Section 8 defines a FEC Scheme for the case of a single flow, 
which is already provided with a source packet sequence number. 
When used with Raptor codes, this scheme is equivalent to that 
defined in [DVBTS] for the case of a single sequenced flow. 


3. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


4. Definitions and Abbreviations 


The definitions, notations, and abbreviations commonly used in this 
document are summarized in this section. 
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4.1. Definitions 
The FEC-specific terminology used in this document is defined in 
[RFC6363]. In this document, as in [RFC6363], the first letter of 
each FEC-specific term is capitalized along with the new terms 
defined here: 


Symbol: A unit of data. Its size, in octets, is referred to as the 
symbol size. 


FEC Framework Configuration Information: Information that controls 
the operation of the FEC Framework. Each FEC Framework instance 
has its own configuration information. 

4.2. Abbreviations 

This document uses abbreviations that apply to the FEC Framework in 

general as defined in [RFC6363]. In addition, this document uses the 

following abbreviations 

FSSI: FEC-Scheme-Specific Information. 

ADU: Application Data Unit 

ADUI: Application Data Unit Information. 

SPI: Source Packet Information. 

MSBL: Maximum Source Block Length 

5. General Procedures for Raptor FEC Schemes 

This section specifies general procedures that apply to all Raptor 

and RaptorQ FEC Schemes, specifically the construction of source 


symbols from a set of source transport payloads. 


For any field defined in this document, the octets are ordered in 
network byte order. 


As described in [RFC6363], for each Application Data Unit (ADU) in a 
source block, the FEC Scheme is provided with: 


o A description of the source data flow with which the ADU is 
associated and an integer identifier associated with that flow. 


o The ADU itself. 


o The length of the ADU. 
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For each ADU, we define the Application Data Unit Information (ADUI) 
as follows: 


Let 
o n be the number of ADUs in the source block. 


o T be the source symbol size in octets. Note: this information is 
provided by the FEC Scheme as defined below. 


o i the index to the (i+1)-th ADU to be added to the source block, 
0 <= i<n. 


o f[i] denote the integer identifier associated with the source data 
flow from which the i-th ADU was taken. 


o F[i] denote a single octet representing the value of f[i]. 


o l[i] be a length indication associated with the i-th ADU -- the 
nature of the length indication is defined by the FEC Scheme. 


o L[i] denote two octets representing the value of 1[i] in network 
byte order (high order octet first) of the i-th ADU. 


o R[i] denote the number of octets in the (i+1)-th ADU. 


o s[i] be the smallest integer such that s[i]*T >= (l[i]+3). Note: 
s[i] is the length of SPI[i] in units of symbols of size T octets. 


o P[i] denote s[i]*T-(l[i]+3) zero octets. Note: P[i] are padding 
octets to align the start of each UDP packet with the start of a 
symbol. 


o ADUI[i] be the concatenation of F[i], L[il, R[il, and P[i]. 


Then, a source data block is constructed by concatenating ADUI[i] for 
i = 0, 1, 2, ... n-1. The source data block size, S, is then given 
by sum {s[i]*T, i=0, ..., n-1}. Symbols are allocated integer 
encoding symbol IDs (ESI) consecutively starting from zero within the 
source block. Each ADU is associated with the ESI of the first 
symbol containing SPI for that packet. Thus, the encoding symbol ID 
value associated with the j-th source packet, ESI[j], is given by 
ESI[j] = 0, for 3=0 and ESI[j] = sum{s[i], i=0,...,(j-1)}, for 
Deise np, 


Source blocks are identified by integer Source Block Numbers. This 
specification does not specify how Source Block Numbers are allocated 
to the source blocks. The Source FEC Packet Identification 
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Information consists of the identity of the source block and the 
encoding symbol ID associated with the packet. 

6. Raptor FEC Schemes for Arbitrary Packet Flows 

6.1. Introduction 
This section specifies a FEC Scheme for the application of the Raptor 
and RaptorQ codes to arbitrary packet flows. This scheme is 


recommended in scenarios where maximal generality is required. 


When used with the Raptor codes specified in [RFC5053], this scheme 
is equivalent to that specified in [MBMSTS]. 


6.2. Formats and Codes 

6.2.1. FEC Framework Configuration Information 

6.2.1.1. FEC Scheme ID 
The value of the FEC Scheme ID for the Fully-Specified FEC scheme 
defined in this section is 1 when [RFC5053] is used and 2 when 
[RFC6330] is used, as assigned by IANA. 


6.2.1.2. Scheme-Specific Elements 


The scheme-specific elements of the FEC Framework Configuration 
information for this scheme are as follows: 


MSBL: The maximum source block length. A non-negative integer less 
than 8192 for FEC Scheme 1 and less than 56403 for FEC Scheme 2, 
in units of symbols. The field type is unsigned integer. 


T: The encoding symbol size. A non-negative integer less than 65536, 
in units of octets. The field type is unsigned integer. 


P: The payload ID format indicator. The P bit shall be set to zero 


to indicate payload ID format A or to one to indicate payload ID 
format B. The field type is unsigned integer. 
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An encoding format for the encoding symbol size, MSBL and payload ID 
format indicator is defined below. 
1 2 3 
012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Symbol Size (T) | MSBL | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|P| Reserved | 


+-+-+-+-+-+-+-+-+ 
Figure 1: FEC-Scheme-Specific Information 


The P bit shall be set to zero to indicate Payload ID format A or to 
one to indicate Payload ID format B. The last octet of FEC-Scheme- 
Specific Information SHOULD be omitted, indicating that Payload ID 
format A is in use. The payload ID format indicator defines which of 
the Source FEC Payload ID and Repair FEC Payload ID formats defined 
below shall be used. Payload ID format B SHALL NOT be used for FEC 
Scheme 1. The two formats enable different use cases. Format A is 
appropriate in case the stream has many typically smaller source 
blocks, and format B is applicable if the stream has fewer large 
source blocks, each with many encoding symbols. 


6.2.2. Source FEC Payload ID 


This scheme makes use of an Explicit Source FEC Payload ID, which is 
appended to the end of the source packets. Two formats are defined 
for the Source FEC Payload ID, format A and format B. The format 
that is used is signaled as part of the FEC Framework Configuration 
Information. 


The Source FEC Payload ID for format A is provided in Figure 2. 


i 2 3 
01234567890123456789012345678901 
+ hh RR RO de de e e e de de dd dd de 4 4 4 4 + + + ++ +++ +++ 
| Source Block Number (SBN) | Encoding Symbol ID (ESI) | 
+ hh RO Rd de de e de de de dd dd q 4 4 4 4 4 + + + +++ ++ +++ 


Figure 2: Source FEC Payload ID - Format A 
Source Block Number (SBN), (16 bits): Identifier for the source block 
that the source data within the packet relates. The field type is 
unsigned integer. 
Encoding Symbol ID (ESI), (16 bits): The starting symbol index of the 


source packet in the source block. The field type is unsigned 
integer. 
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The Source FEC Payload ID for format B is provided in Figure 3. 


1 2 3 
C1 .2.3°4.5 6 7-8-9 OC 1.2-3 475 6.9.8.9 0-1 2.3.45 6 9-8. 9.0 4 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| SBN | Encoding Symbol ID (ESI) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: Source FEC Payload ID - Format B 


Source Block Number (SBN), (8 bits): Identifier for the source block 
that the source data within the packet relates. The field type is 
unsigned integer. 


Encoding Symbol ID (ESI), (24 bits): The starting symbol index of the 
source packet in the source block. The field type is unsigned 
integer. 


6.2.3. Repair FEC Payload ID 


Two formats for the Repair FEC Payload ID, format A and format B, are 
defined below. 


The Repair FEC Payload ID for format A is provided in Figure 4. 


1 2 3 
01234567890123 456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +H 
| Source Block Number (SBN) | Encoding Symbol ID (ESI) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Source Block Length (SBL) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 4: Repair FEC Payload ID - Format A 
Source Block Number (SBN), (16 bits): Identifier for the source block 
that the repair symbols within the packet relate. For format A, 


it is of size 16 bits. The field type is unsigned integer. 


Encoding Symbol ID (ESI), (16 bits): Identifier for the encoding 
symbols within the packet. The field type is unsigned integer. 


Source Block Length (SBL), (16 bits): The number of source symbols in 
the source block. The field type is unsigned integer. 
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The Repair FEC Payload ID for format B is provided in Figure 5. 


1 2 3 
01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SBN | Encoding Symbol ID (ESI) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Source Block Length (SBL) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 5: Repair FEC Payload ID - Format B 


Source Block Number (SBN), (8 bits): Identifier for the source block 
that the repair symbols within the packet relate. For format B, 
it is of size 8 bits. The field type is unsigned integer. 


Encoding Symbol ID (ESI), (24 bits): Identifier for the encoding 
symbols within the packet. The field type is unsigned integer. 


Source Block Length (SBL), (16 bits): The number of source symbols in 
the source block. The field type is unsigned integer. 


The interpretation of the Source Block Number, encoding symbol ID, 
and Source Block Length is defined by the FEC Code Specification in 
[RFC5053] for FEC Scheme 1 and [RFC6330] for FEC Scheme 2. 


6.3. Procedures 
6.3.1. Source Symbol Construction 


FEC Scheme 1 and FEC Scheme 2 use the procedures defined in Section 5 
to construct a set of source symbols to which the FEC Code can be 
applied. The sender MUST allocate Source Block Numbers to source 


blocks sequentially, wrapping around to zero after Source Block 
Number 65535 (format A) or 255 (format B). 


During the construction of the source block: 


o the length indication, 1[i], included in the Source Packet 
Information for each packet shall be the transport payload length, 
i.e., the length of the ADU. 


o the value of s[i] in the construction of the Source Packet 
Information for each packet shall be the smallest integer such 
that s[i]*T >= (1[1]+3). 
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6.3.2. Repair Packet Construction 


For FEC Scheme 1 [RFC5053], the ESI value placed into a repair packet 
is calculated as specified in Section 5.3.2 of [RFC5053]. 


For FEC Scheme 2 [RFC6330], the ESI value placed into a repair packet 
is calculated as specified in Section 4.4.2 of [RFC6330]. 


In both cases, K is identical to SBL. 


6.4. FEC Code Specification 


The FEC encoder defined in [RFC5053] SHALL be used for FEC Scheme 1 
and the FEC encoder defined in [RFC6330] SHALL be used for FEC Scheme 
2. For both FEC Scheme 1 and FEC Scheme 2, the source symbols passed 
to the FEC encoder SHALL consist of the source symbols constructed 
according to Section 6.3.1. Thus, the value of the parameter K used 
by the FEC encoder (equal to the Source Block Length) may vary 
amongst the blocks of the stream but SHALL NOT exceed the Maximum 
Source Block Length signaled in the FEC-Scheme-Specific Information. 
The symbol size, T, to be used for source block construction and the 
repair symbol construction is equal to the encoding symbol size 
signaled in the FEC-Scheme-Specific Information. 


7. Optimized Raptor FEC Scheme for Arbitrary Packet Flows 
7.1. Introduction 


This section specifies a slightly modified version of the FEC Scheme 
specified in Section 6 that is applicable to scenarios in which only 
relatively small block sizes will be used. These modifications admit 
substantial optimizations to both sender and receiver 
implementations. 


In outline, the modifications are: 


o All source blocks within a stream are encoded using the same 
source block size. Code shortening is used to encode blocks of 
different sizes. This is achieved by padding every block to the 
required size using zero symbols before encoding. The zero 
symbols are then discarded after decoding. The source block size 
to be used for a stream is signaled in the Maximum Source Block 
Length (MSBL) field of the scheme-specific information. The 
extended source block is constructed by adding zero or more 
padding symbols such that the total number of symbols, MSBL, is 
one of the values listed in Section 7.4. Each padding symbol 
consists of T octets where the value of each octet is zero. MSBL 
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MUST be selected as the smallest value of the possible values in 
Section 7.4 that is greater than or equal to K. 


o The possible choices of the MSBL for a stream is restricted to a 
small specified set. This allows explicit operation sequences for 
encoding and decoding the restricted set of source block lengths 
to be pre-calculated and embedded in software or hardware. 


When used with the Raptor codes specified in [RFC5053], this scheme 
is equivalent to that specified in [DVBTS] for arbitrary packet 
flows. 

7.2. Formats and Codes 

7.2.1. FEC Framework Configuration Information 

7.2.1.1. FEC Scheme ID 
The value of the FEC Scheme ID for the Fully-Specified FEC scheme 
defined in this section is 3 when [RFC5053] is used and 4 when 
[RFC6330] is used, as assigned by IANA. 

7.2.1.2. FEC-Scheme-Specific Information 
The elements for FEC Scheme 3 are the same as specified for FEC 
Scheme 1, and the elements specified for FEC Scheme 4 are the same as 


specified for FEC 2, as specified in Section 6.2.1.2, except that the 
MSBL value is as defined in Section 7.4. 


7.2.2. Source FEC Payload ID 


The elements for FEC Scheme 3 are the same as specified for FEC 
Scheme 1, and the elements specified for FEC Scheme 4 are the same as 
specified for FEC 2, as specified in Section 6.2.2. 


7.2.3. Repair FEC Payload ID 
The elements for FEC Scheme 3 are the same as specified for FEC 


Scheme 1, and the elements specified for FEC Scheme 4 are the same as 
specified for FEC 2, as specified in Section 6.2.3. 


7.3. Procedures 
7.3.1. Source Symbol Construction 


See Section 6.3.1. 
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7.3.2. Repair Packet Construction 


The number of repair symbols contained within a repair packet is 
computed from the packet length. The ESI value placed into a repair 
packet is calculated as X + MSBL - SBL, where X would be the ESI 
value of the repair packet if the ESI were calculated as specified in 
Section 5.3.2 of [RFC5053] for FEC Scheme 3 and as specified in 
Section 4.4.2 of [RFC6330] for FEC Scheme 4, where K=SBL. The value 
of SBL SHALL be, at most, the value of MSBL. 


7.4. FEC Code Specification 


The FEC encoder defined in [RFC5053] SHALL be used for FEC Scheme 3 
and the FEC encoder defined in [RFC6330] SHALL be used for FEC Scheme 
4. The source symbols passed to the FEC encoder SHALL consist of the 
source symbols constructed according to Section 6.3.1 extended with 
zero or more padding symbols. The extension SHALL be such that the 
total number of symbols in the source block is equal to the MSBL 
signaled in the FEC-Scheme-Specific Information. Thus, the value of 
the parameter K used by the FEC encoder is equal to the MSBL for all 
blocks of the stream. Padding symbols shall consist entirely of 
octets set to the value zero. The symbol size, T, to be used for the 
source block construction and the repair symbol construction, is 
equal to the encoding symbol size signaled in the FEC-Scheme-Specific 
Information. 


For FEC Scheme 3, the parameter T SHALL be set such that the number 
of source symbols in any source block is, at most, 8192. The MSBL 
parameter, and hence the number of symbols used in the FEC Encoding 
and Decoding operations, SHALL be set to one of the following values: 


101, 120, 148, 164, 212, 237, 297, 371, 450, 560, 680, 842, 1031, 
1139, 1281 


For FEC Scheme 4, the parameter T SHALL be set such that the number 
of source symbols in any source block is less than 56403. The MSBL 
parameter SHALL be set to one of the supported values for K’ defined 
in Section 5.6 of [RFC6330]. 
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8. Raptor FEC Scheme for a Single Sequenced Flow 

8.1. Formats and Codes 

8.1.1. FEC Framework Configuration Information 

8.1.1.1. FEC Scheme ID 
The value of the FEC Scheme ID for the Fully-Specified FEC scheme 
defined in this section is 5 when [RFC5053] is used and 6 when 


[RFC6330] is used, as assigned by IANA. 


8.1.1.2. Scheme-Specific Elements 


The elements for FEC Scheme 5 are the same as specified for FEC 
Scheme 1, and the elements specified for FEC Scheme 6 are the same as 
specified for FEC 2, as specified in Section 6.2.1.2. 


8.1.2. Source FEC Payload ID 


The Source FEC Payload ID field is not used by this FEC Scheme. 
Source packets are not modified by this FEC Scheme. 


8.1.3. Repair FEC Payload ID 


Two formats for the Repair FEC Payload ID are defined, format A and 
format B. 


1 2 3 
0.1234 5 678901:2 345678901223 403.67.8-901 
dd + + A q e hd de + q q ta + q 4 $ + d+ + + +++ +++ +++ 
| Initial Sequence Number | Source Block Length 
d+ WE + q dd E + q 4 + ++ + + +++ Eh EEAS 
| Encoding Symbol ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 6: Repair FEC Payload ID - Format A 


Initial Sequence Number (Flow i ISN), (16 bits): This field specifies 
the lowest 16 bits of the sequence number of the first packet to 
be included in this sub-block. If the sequence numbers are 
shorter than 16 bits, then the received Sequence Number SHALL be 
logically padded with zero bits to become 16 bits in length, 
respectively. The field type is unsigned integer. 


Source Block Length (SBL), (16 bits): This field specifies the length 
of the source block in symbols. The field type is unsigned 
integer. 
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Encoding Symbol ID (ESI), (16 bits): This field indicates which 
repair symbols are contained within this repair packet. The ESI 
provided is the ESI of the first repair symbol in the packet. The 
field type is unsigned integer. 


I 2 3 
(REECH 3:44. 5.6 7 82 90-123 AS: 6-778 9 OT 2) EE E EE 8. 90-1 
FPP rt ata E tata E E E E E EE EE? 
| Initial Sequence Number | Source Block Length 
KE E E E E E E E E EE? 
| Encoding Symbol ID 
KE E E E E E E E E 


Figure 7: Repair FEC Payload ID - Format B 


Initial Sequence Number (Flow i ISN), (16 bits): This field specifies 
the lowest 16 bits of the sequence number in the first packet to 
be included in this sub-block. If the sequence numbers are 
shorter than 16 bits, then the received Sequence Number SHALL be 
logically padded with zero bits to become 16 bits in length, 
respectively. The field type is unsigned integer. 


Source Block Length (SBL), (16 bits): This field specifies the length 


of the source block in symbols. The field type is unsigned 
integer. 

Encoding Symbol ID (ESI); (24 bits): This field indicates which 
repair symbols are contained within this repair packet. The ESI 


provided is the ESI of the first repair symbol in the packet. The 
field type is unsigned integer. 


8.2. Procedures 

8.2.1. Source Symbol Construction 
FEC Scheme 5 and FEC Scheme 6 use the procedures defined in Section 5 
to construct a set of source symbols to which the FEC code can be 
applied. 
During the construction of the source block: 
o the length indication, 1[i], included in the Source Packet 


Information for each packet shall be dependent on the protocol 


carried within the transport payload. Rules for RIP are specified 
below. 
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o the value of s[i] in the construction of the Source Packet 
Information for each packet shall be the smallest integer such 
that s[i]*T >= (1[1]+3) 


8.2.2. Derivation of Source FEC Packet Identification Information 


The Source FEC Packet Identification Information for a source packet 
is derived from the sequence number of the packet and information 
received in any repair FEC packet belonging to this source block. 
Source blocks are identified by the sequence number of the first 
source packet in the block. This information is signaled in all 
repair FEC packets associated with the source block in the Initial 
Sequence Number field. 


The length of the Source Packet Information (in octets) for source 
packets within a source block is equal to the length of the payload 
containing encoding symbols of the repair packets (i.e., not 
including the Repair FEC Payload 1D) for that block, which MUST be 
the same for all repair packets. The Application Data Unit 
Information Length (ADUIL) in symbols is equal to this length divided 
by the encoding symbol size (which is signaled in the FEC Framework 
Configuration Information). The set of source packets included in 
the source block is determined by the Initial Sequence Number (ISN) 
and Source Block Length (SBL) as follows: 


Let, 


o I be the Initial Sequence Number of the source block 


o LP be the Source Packet Information Length in symbols 

o LB be the Source Block Length in symbols 

Then, source packets with sequence numbers from I to I +(LB/LP)-1 
inclusive are included in the source block. The Source Block Length, 
LB, MUST be chosen such that it is at least as large as the largest 
Source Packet Information Length LP. 

Note that if no FEC repair packets are received, then no FEC decoding 
is possible, and it is unnecessary for the receiver to identify the 


Source FEC Packet Identification Information for the source packets. 


The encoding symbol ID for a packet is derived from the following 
information: 


o The sequence number, Ns, of the packet 


o The Source Packet Information Length for the source block, LP 
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o The Initial Sequence Number of the source block, I 


Then, the encoding symbol ID for the packet with sequence number Ns 
is determined by the following formula: 


ESI = (Ns - 1) * LP 


Note that all repair packets associated to a given source block MUST 
contain the same Source Block Length and Initial Sequence Number. 


Note also that the source packet flow processed by the FEC encoder 
MUST have consecutive sequence numbers. In case the incoming source 
packet flow has a gap in the sequence numbers, then implementors 
SHOULD insert an ADU in the source block that complies to the format 
of the source packet flow, but is ignored at the application with 
high probability. For additional guidelines, refer to [RFC6363], 
Section 10.2, paragraph 5. 


8.2.3. Repair Packet Construction 
See Section 7.3.2 
8.2.4. Procedures for RTP Source Flows 


In the specific case of RTP source packet flows, the RTP Sequence 
Number field SHALL be used as the sequence number in the procedures 
described above. The length indication included in the Application 
Data Unit Information SHALL be the RTP payload length plus the length 
of the contributing sources (CSRCs), if any, the RTP Header 
Extension, if present, and the RTP padding octets, if any. Note that 
this length is always equal to the UDP payload length of the packet 
minus 12. 


8.3. FEC Code Specification 


The elements for FEC Scheme 5 are the same as specified for FEC 
Scheme 3, and the elements specified for FEC Scheme 6 are the same as 
specified for FEC 4, as specified in Section 7.4. 


9. Security Considerations 


For the general security considerations related to the use of FEC, 
refer to [RFC6363]. Also consider relevant security considerations 
in [RFC5053] and [RFC6330]. No security vulnerabilities specific to 
this document have been identified. 
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10. Session Description Protocol (SDP) Signaling 


This section provides an SDP [RFC4566] example. The syntax follows 
the definition in [RFC6364]. Assume we have one source video stream 
(mid:S1) and one FEC repair stream (mid:R1). We form one FEC group 
with the "a=group:FEC-FR S1 R1" line. The source and repair streams 
are sent to the same port on different multicast groups. The repair 
window is set to 200 ms. 


v=0 

o=ali 1122334455 1122334466 IN IP4 fec.example.com 
s=Raptor FEC Example 

t=0 0 

a=group:FEC-FR S1 R1 

m=video 30000 RTP/AVP 100 

c=IN IP4 233.252.0.1/127 

a=rtpmap:100 MP2T/90000 

a=fec-source-flow: id=0 

a=mid:S1 

m=application 30000 UDP/FEC 

c=IN IP4 233.252.0.2/127 

a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A 
a=repair-window:200ms 

a=mid:R1 


11. Congestion Control Considerations 


For the general congestion control considerations related to the use 
of FEC, refer to [RFC6363]. 


12. IANA Considerations 

12.1. Registration of FEC Scheme IDs 
The value of FEC Scheme IDs is subject to IANA registration. For 
general guidelines on IANA considerations as they apply to this 
document, refer to [RFC6363]. 
This document registers six values in the "FEC Framework (FECFRAME) 
FEC Encoding IDs" registry (http://www.iana.org/assignments/ 


rmt-fec-parameters/) as provided in Table 1. Each value refers to a 
Fully-Specified FEC scheme. 
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Ho spare a PES RS RS ES + 
| FEC | FEC Scheme | Reference 
Encoding Description 
ID 
Ho $ E AZ O + 
| 1 | Raptor FEC Scheme | Section 6 in this document using | 
| | for Arbitrary | [RFC5053] 
| | Packet Flows | | 
KE KE KEE + 
| 2 | RaptorQ FEC Scheme | Section 6 in this document using | 
| | for Arbitrary | [RFC6330]. 
| | Packet Flows | | 
Ho $ nA AZ e A E + 
| 3 | Raptor FEC Scheme | Section 7 in this document using | 
| | Optimized for | Raptor [RFC5053]. | 
Arbitrary Packet 
Flows 
KE KE KEE + 
| 4 | RaptorQ FEC Scheme | Section 7 in this document 
| | Optimized for | using RaptorQ [RFC6330]. 
| | Arbitrary Packet | | 
| | Flows | | 
Ho il AZ O + 
| 5 | Raptor FEC Scheme | Section 8 in this document using | 
| | for a Single | Raptor [RFC5053]. 
| | Sequence Flow | | 
Ho fa = 22222223 Ponte EE + 
6 RaptorQ FEC Scheme Section 8 in this document using 
for a Single RaptorQ [RFC6330]. 
| | Sequence Flow | | 
Ho $ E AZ O + 


Table 1: FEC Framework (FECFRAME) FEC Encoding IDs 
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